Routing data packets in a compressed-header domain

ABSTRACT

The invention concerns routing of data packets in a header-compressed domain. According to the method described, routing a data packet with a compressed header section and an uncompressed payload section comprises steps of receiving the data packet at an ingress interface, routing the data packet to an egress interface, and forwarding the data packet to the egress interface. According to this method, the compressed header section remains unchanged between the ingress interface and the egress interface. Various implementations of this method are described, including the use of the header compression context identifier (HCCID) by for routing the packets to the correct egress interface. Accordingly, a decompressor and a router are also disclosed.

FIELD OF THE INVENTION

The present invention relates to a method for routing a data packet witha compressed header section, and to a method for routing a data packetwith a header section from an originating network node to a destinationnetwork node through at least one intermediate router. It furtherrelates to a decompressor device, a router device, and a communicationnetwork.

BACKGROUND OF THE INVENTION

In communication networks using packet data transport, individual datapackets carry information that is needed to transport the packet from asource application to a destination application in a header section. Theactual data to be transmitted is contained in a payload section.

The transport path of a data packet from a source application to adestination application usually involves multiple intermediate stepsrepresented by network nodes interconnected through communication links.These network nodes, called packet switches or routers, receive the datapacket and forward it to a next intermediate router until a destinationnetwork node is reached that will deliver the payload of the data packetto the destination application. Due to contributions of differentprotocol layers to the transport of the data packet, the length of aheader section of a data packet may even exceed the length of thepayload section.

Data compression of the header section may therefore be employed toobtain better utilization of the link layer for delivering the payloadto a destination application. Header compression is reducing the size ofa header by removing header fields or by reducing the size of headerfields. The term header field refers to an entry in the headercontaining a specified kind of information. For instance, a header fieldmay contain the network address of the destination network node of theparticular data packet.

Data compression in the header is done by coding the data in a way suchthat a decompressor can reconstruct the header if its context state isidentical to the context state used when compressing the header. Ingeneral header compression works by occasionally sending a packet with afull header. Subsequent compressed headers refer to the contextestablished by the full header and may contain incremental changes tothe context.

Header compression may include the network layer, e.g., an InternetProtocol (IP) header, the transport layer, such as an User DatagramProtocol (UDP) header, a Transport Control Protocol (TCP) header, aReal-time Transport Protocol (RTP) header and even the applicationlayer, such as a Hypertext Transport Protocol (http) header.

Access networks are typically built using copper cable or microwaveradio transmission. In radio access networks, wireless communicationlinks are provided to a source and/or destination station such as amobile station, be it a mobile telephone or a mobile computer.Capacities of access networks are usually limited (e.g., N×E1 capacity).An extensive capacity upgrade and/or media change, e.g., to fiber, in anaccess network is very expensive for the operator. Therefore methods tosave bandwidth in the access network are very important. Headercompression is one such method.

On the transport path the routers involved need the routing informationcontained in the header to decide on the next router the data packet isforwarded to. Therefore, compressed headers are decompressed at an inputport of an intermediate router before routing the packet based on theinformation contained in the header and a routing table maintained bythe router. After routing the packet, the header is compressed again.The data packet is forwarded to an output port of the router, from whereit is transmitted to the next router on the transport path.

However; compressing and decompressing the header in a router takes upprocessing capacity of that router. Regarding the end-to-end delay inthe transport of a packet, the benefit of faster transmission ofcompressed header data due to the reduced header size may in part beoutweighed by processing time needed to decompress and compress theheader, especially at intermediate routers.

In Multi Protocol Label Switching (MPLS), such as described in thecurrent version of Request for Comments (RFC) 3031, the entire set ofpossible packets to be received by a given router is partitioned into aset of “Forwarding Equivalence Classes” (FECs). All packets which belongto a particular FEC and which travel from that router will follow thesame path. The assignment of a particular packet to a particular FEC isdone once, as the packet enters the network. The FEC to which the packetis assigned is encoded as a short fixed length value known as a “label”.The packets are “labeled” before they are forwarded. When a packet isforwarded to its next hop, the label is sent along with it. At the nextrouter, the label is used as an index into a table which specifies thefollowing hop, and a new label. The old label is replaced with the newlabel, and the packet is forwarded to its next hop.

In MPLS forwarding, therefore, all forwarding is driven by the labels.This has the advantage that MPLS forwarding can be done by routerswithout analyzing the network-layer headers, or not capable of analyzingthe network-layer headers at adequate speed. However, implementingsupport for MPLS is costly.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide a simplemethod for routing a data packet with a compressed header section thatreduces the processing load on the routers.

It is a further object of the present invention to provide a simplemethod for routing a data packet with a header section and a payloadsection from an originating, router to a destination router through atleast one intermediate router that reduces the processing load on therouters.

It is a further object of the invention to provide a decompressor deviceallowing to reduce the processing load in the routing of a data packetin a router device.

It is a further object of the invention to provide a router device thatcauses only a short delay in the transmission of a data packet.

Finally, it is an object of the present invention to provide acommunication network comprising a plurality of network nodescommunicating with each other through a plurality communication linksthat allows for fast and reliable transmission of data packets even whenpacket loss cannot be excluded.

These objects are achieved by a method for routing a data packet with acompressed header section as claimed in claim 1, by a method for routinga data packet with a header section from an originating network node toa destination network node through at least one intermediate router asclaimed in claim 29, by a decompressor device as claimed in claim 33, bya router device as claimed in claim 39, by a router device as claimed inclaim 44 and by a communication network as claimed in claim 48.

According to a first independent aspect of the invention, a method forrouting a data packet comprising a header section and a payload sectionis provided, said header section comprising a compressed header sectioncontaining coded information including routing information. The methodcomprises the following steps:

-   -   receiving said data packet at an input interface,    -   routing said data packet to an output interface,    -   forwarding said data packet to said output interface.

According to this method of the invention the routing step comprisesascertaining said routing information. Also, according to the invention,said coded information remains unchanged in said routing and forwardingsteps.

Since the coded information remains the same in the routing andforwarding steps, the routing method of the invention allows to skip the(re)compression step performed by intermediate routers known in the art.Compression of a header section of a data packet needs only be performedat the originating network node. The originating network node making theheader compression in the first place may for instance be an IP basednode B and IP RNC according to the Third Generation Project Partnership(3GPP) release 5 standard, or any intermediate router on thetransmission path.

Typically, compression consumes more time and processor capacity thandecompression. Therefore, by leaving the information unchanged in therouting and forwarding steps, the compression step is unnecessary andthe processor load in the intermediate router is reduced. Not having todo recompression also allows to reduce the delay caused by the routingof the data packet.

Note that leaving the information unchanged does not necessarily implythat the code containing the information in compressed form remains thesame. According to the invention, different codes may be used for thesame information. The term coded information also includes the case,where the code contains a reference to an information source, such as aline of a table, where the desired information can be ascertained.

According to the method of the invention, header fields, which accordingto existing standards are to be changed in every router, such as thetime-to-live field (TTL), are either not part of the compressed headersection. This way, they can be accessed without decompression andchanged according to a predetermined rule, depending on the field. As analternative, the complete header-compressed transmission path fromsource to destination is considered as one hop for the TTL count.Therefore, the TTL-field does not have to be changed duringheader-compressed transmission according to the method of the invention.

According to an embodiment of the method of the invention, the routingstep comprises a step of reading header data from the compressed headersection. This reading step allows the router to ascertain theinformation needed for a routing decision and contained in thecompressed header section of an incoming packet. The compressed headersection remains unchanged in this reading step.

According to a first preferred embodiment of the routing method of theinvention said reading step comprises reading a header compressioncontext identifier from the compressed header section. A headercompression context identifier (HCCID) is a unique number identifyingthe header compression context that is used to decompress a compressedheader. Therefore, the HCCID of an incoming data packet is coded routinginformation. It allows to ascertain the routing information by referringto a defined header compression context. The header compression contextcontains the routing information needed or allows to deduce it accordingto predetermined algorithms well known in the art.

The HCCID is carried as uncompressed data in full headers and headerswith compressed header sections, hereinafter also called compressedheaders. Therefore, the HCCID of an incoming data packet containsrouting information that can be read from the header without performinga decompressing step. The HCCID need not necessarily be a part of thecompressed header section. It may also be contained in an uncompressedsection of the header. This embodiment has the advantage, thatadditional CPU capacity is saved that would otherwise be necessary fordecompressing the compressed header section.

It is obvious that all header sections of a data packet may becompressed in the data packet to enhance the transportation speed of thepacket. Routing information is contained in a network-layer headersection. Therefore, this invention works with data packets containing acompressed network-layer header section or other additional compressedheader sections or with data packets in which all header sections arecompressed.

The header compression context may be described as the state which thecompressor of the header or header section uses to compress, and thedecompressor of this header or header section uses to decompress thisheader or header section. For an originating node the header compressioncontext is the last uncompressed version of the header sent to the firstintermediate router. In general, according to the invention, for thefirst and the following intermediate routers, the header compressioncontext is the uncompressed version of the last full protocol headerreceived over the link from the originating node or the previousintermediate router, respectively. According to the invention,intermediate routers do not need context information related to headersections of other layers, e.g., concerning a compressed transport layerheader, such as a Transfer-Control Protocol (TCP) header, or a UserDatagram Protocol (UDP)/Real-time Transport Protocol (RTP) header. Thelast full header received over the link contains all information neededfor routing.

Therefore, according to the first preferred embodiment of the invention,intermediate routers may maintain a header compression context ofreduced size, containing only a part of the full header. The reducedcontext must contain the information of the last uncompressed headerthat is necessary for correct IP routing, such as the IP destinationaddress. It may also contain the IP source address and/or a serviceclass. In contrast, header information not needed for IP routing, forexample information from the mentioned User Datagram Protocol (UDP)/Real-time Transport Protocol (RTP) header contained in the full headercompression context, need not be maintained as part of the headercompression context by intermediate routers for the purpose of themethod of the invention.

There are several alternative ways to implement the present firstpreferred embodiment of the invention. When implementing the firstpreferred method of the invention, care has to be taken to assign uniqueheader compression identification. This is not automatically the case,especially when compression is done over multiple links. The termmultiple links refers to distributing IP traffic in the network in orderto handle heavy traffic flows and reduce congestion. Multiple links maytherefore be used for load balancing. The implementations of the methodof the invention described in the following paragraphs each provide away of assigning unique header compression context identifiers over apath having multiple hops and allowing for branching.

In the following, to avoid confusion, the term “implementation” is usedwith the same general meaning as “embodiment”. An embodiment will benamed implementation if in addition to the features of a previouslydescribed embodiment it has further defining features.

Preferably, in a first implementation of the present first preferredembodiment of the invention said routing step comprises a step ofassigning a second header compression context identifier to said datapacket and a step of replacing said first header compression contextidentifier by said second header compression context identifier in saiddata packet. The second HCCID is hereinafter also named outgoing headercompression context identifier (HCCID).

Each router performing the present implementation may use the completespace of possible HCCID values to assign an outgoing HCCID. Forinstance, the outgoing HCCID is one of a predetermined set of numbers.There is no need for assigning a certain subspace of HCCID values toeach router in a network in this implementation in order to guaranteeuniqueness of the HCCID. Uniqueness of the outgoing HCCID is guaranteedby the fact that the HCCID is defined by a given router performing thepresent implementation of the routing method for a given link and for agiven header compression context.

The outgoing HCCID therefore unambiguously corresponds to one linkbetween the router performing the routing method and an address for thenext hop for the data packet to be forwarded, given the current headercompression context. Accordingly, the data packet is forwarded to theoutput interface connecting the router performing the routing method tothe network node of the next hop, be it another intermediate router orthe destination network node. The HCCID of the incoming data packet isthus switched at each intermediate router of a transmission path.

A header compression context table and a switching table is created andmaintained by each intermediate router in the transmission path. Theheader compression context table assigns to an incoming HCCID thecurrent header compression context, i.e., the last full header in aparticular flow. The switching table assigns to a first (incoming) HCCIDcontained in an incoming data packet a next-hop address or,respectively, an output port assigned to that next-hop address, and anoutgoing HCCID.

Information needed for maintaining the switching table is taken from thecurrent compression context table. In all known header compressionmethods the header compression context is maintained by letting a flowof data packets from a source to a destination network node occasionallycontain packets with uncompressed headers. The same HCCID as in thecompression context will be carried in the header of following incomingpackets of that flow which have compressed headers, as long as theyshare the same header compression context. Once a new compressioncontext is received, the HCCID is read from the context and thecompression context table will be maintained. On the basis of the datain the compression context table an address of the next hop can beassigned to a given (incoming) HCCID.

The full header contains, among other data, a destination IP address andan (incoming) HCCID. These data are used to maintain the headercompression context table. A new entry to the header compression contexttable is created for each new header compression context. The entry maybe a line in the table with a plurality of columns, one for the HCCID,an additional column for each information element contained in thecompression context, such as the source IP address, the destination IPaddress, and so forth. The number of columns is in the presentimplementation preferably restricted to the information elementsnecessary for routing purposes. This is the destination IP address, and,if supported, a service class identifier such as the DiffServ CodePoint.

Maintenance of the header compression context table preferably alsoinvolves deleting unnecessary entries from the table to keep the tableshort and the used HCCID space small. This may be governed by a wellknown aging algorithm.

Maintaining the header compression context table triggers maintenance ofthe switching table. After routing a new compression context to anassigned output port the (incoming) HCCID of the data packet containingthe context is replaced by an outgoing HCCID. A new entry in theswitching table is created. This new entry is a line in the switchingtable with three columns, one for the incoming HCCID, one for theoutgoing HCCID and one for the assigned output port or next-hop address,respectively.

Note that the steps of assigning an outgoing HCCID and replacing theincoming HCCID are performed for compressed headers as well as foruncompressed headers. Performing these steps in uncompressed headers isnecessary to allow a following router in the transmission path to relatethe HCCID it receives to the right compression context.

In order to provide an option for multiple links, the switching tablemay have a plurality of switching table entries, that may be assigned toone given incoming HCCID. Each switching table entry comprises anoutgoing HCCID and a next-hop address/an output port which is differentfrom that of the other entries assigned to the given incoming HCCID.Each possible assignment, therefore, is represented by an individualentry to the switching table. The actual assignment decision about theoutgoing HCCID may be based on an input from a load balancing processrun by the intermediate router. Such load balancing methods are wellknown in the art. Again, uniqueness of the outgoing HCCID is guaranteedby the fact that each link is assigned an individual HCCID.

Maintenance of the switching table may include an aging algorithmsimilar to that of learning switches. Especially, there may be a presetlife time for entries to the switching table. A table entry may beerased after not having initiated a transmission within a certain timespan, e.g., 5 minutes.

Routing information can thus be deduced from the incoming headercompression context ID of a header-compressed packet alone. The deducedrouting information may be temporarily attached to the packet inside theintermediate router, but before forwarding the data packet to the nextrouter, the attached information is removed.

In a second, alternative implementation of the present first preferredembodiment of the invention, representing an independent solution forproviding uniqueness of the HCCID, the HCCID space is partitioned suchthat each network node that may be a starting point of a headercompressed transmission path manages an individual HCCID subspace. Thissubspace has no overlap with any other HCCID subspace managed by othernetwork nodes. This may for instance be achieved by using an HCCIDformat that includes the IP address of the network node that is thestarting point of the header compressed transmission path. It is wellknown that each network node using the Internet Protocol has a unique IPaddress. It has to be noted that due to the length of the IP addresswhich is 16 octets in the coming version 6 of the Internet Protocol, theheader compression performance is not optimal.

The HCCID of the present implementation contains a certain number ofadditional bits allowing to identify the particular header compressioncontext from previous and later header compression contexts sent by thatstarting-point node. The originating network node making the headercompression in the first place may for instance be an IP based node Band RNC according to the Third Generation Project Partnership (3GPP)release 5 standard, or any intermediate router on the transmission path.

Unique assignment of HCCID need not be based, as described above, on anIP network address of the starting point of the header-compressed path.Any other unique addressing system, or, more generally, any partition ofa space of identifiers that gives each router, that first performscompression of a header, a set of “proprietary” identifiers which issufficient with respect to the required transmission capacity of thatrouter, will be in accordance with this method.

An aging algorithm may be implemented to allow to reuse the same HCCIDafter a predetermined time span with no transmission initiated usingthat HCCID.

This second implementation has the advantage that the switching tableused by intermediate routers is simpler. There is no step of assigningan outgoing HCCID necessary in this method. The HCCID remains the samefrom the starting point to the end point of the header-compressedtransmission path. The switching table used simply assigns an outputport for the next hop to a given HCCID.

Uniqueness is also guaranteed for multiple links in this implementationdue to fact that uniqueness of the HCCID is given in the whole network.Again, there are as many switching table entries as there are possiblelinks for the next hop for a given HCCID. The routing decision is basedon input from a load balancing algorithm.

A disadvantage of the present implementation is that the HCCID isnecessarily longer than in the first implementation. The longer formatof the HCCID is owed to the fact that uniqueness is not just guaranteedover a link but network-wide.

A second preferred embodiment of the routing method of the inventioncomprises, before said routing step, a step of decompressing routinginformation from said compressed header section.

In a first implementation of this second preferred embodiment thedecompressing step comprises decompressing said complete compressedheader section. This method has the advantage of making all compressedheader information available for routing contained in the network-layerheader section. However, in comparison with the first preferredembodiment it involves more processing effort to decompress the wholeheader section. Routing may be done in this implementation usingconventional routing tables known in the art.

In a second implementation of this preferred embodiment, thedecompressing step comprises decompressing a network layer address of adestination network node, such as an IP address. In addition, thisimplementation may comprise decompressing a service class identifier.This information will allow to assign an output port to the data packetin the routing step.

Due to the standardized format of the compressed header the exactposition of the compressed data allowing to extract the destinationnetwork node address using the current compression context is known.Selective decompression of this section of the compressed header istherefore straight forward. It involves counting the header bits to apredetermined count number and copying a certain number of header bitsfrom there on. It is noted that decompression in the present sense doesnot imply replacing or discarding any compressed information. Thecompressed header and, therefore, the routing information containedtherein, remains unchanged in the routing and forwarding steps. This isachieved by selectively copying data from the compressed header andprocessing these copied data to obtain the desired decompressed data.

The decompressed header data, whether complete header or selected data,is not used to replace the compressed header. The decompressed data may,in a further embodiment of the method of the invention, be included atleast partly into the data packet.

Inclusion of said decompressed header data is preferably done byattaching it to said data packet in front of said compressed headersection, such that said decompressed header data can be forwarded tosaid egress interface before said compressed header section. This way,the decompressed information can be analyzed first for forwardingpurposes.

In a further embodiment, a step of removing at least a part of saiddecompressed header data from said data packet is included beforeforwarding the data packet. Preferably, all decompressed header data isremoved from the data packet.

In order to ensure quality of service, a further embodiment of thepresent invention includes provisions for differentiated services bycomprising a step of classifying said data packet according to a serviceclass. Such classification may be performed using the knownDifferentiated Services (DiffServ) scheme by assigning a DiffServ Codepoint (DSCP) to the data packet. This classifying step is preferablyperformed after said routing step. The classifying step preferablycomprises a step of reading a service classification code element from aheader compression context table. The right entry in the headercompression context table is accessed using the HCCID introduced aboveor the network node identifier, also described above. The classifyingstep is preferably performed before said removing step.

The removing step comprises in a further embodiment removing saiddecompressed header data except for said service classification codeelement. However, carrying the service classification element betweenrouters is not necessary. The service classifier may be removed beforeforwarding the data packet to the next router.

When providing differentiated services the forwarding step preferablycomprises a step of placing said data packet into one of a plurality ofqueues, the chosen queue corresponding to a value of said classificationcode point. The service classification code element may be removed fromthe data packet before placing it in the assigned queue.

The present method of the invention is preferably applied in radio ormicrowave access networks, which due to the nature of the air interfaceoffer limited bandwidth in serial transmission of data. It may also beused in any other access network, like copper-based access networks,e.g., Public Switched Telephone Networks (PSTN).

According to a second aspect of the invention the method of theinvention as described so far is employed in a method for routing a datapacket with a compressed header section from an originating node to adestination node through at least one intermediate router. This methodcomprises the steps of

-   -   a) at said originating router, routing said data packet to said        intermediate router    -   b) at said originating router, compressing at least a part of        said header section containing routing information    -   c) forwarding said data packet from said originating router to        said intermediate router    -   d) at said intermediate router, which is communicating with said        originating router through said input interface, performing a        routing method as described above, said output interface        communicating with a next intermediate router or said        destination router, respectively,    -   e) repeating step d) for any further intermediate router,    -   f) at said destination router, decompressing said compressed        network-layer header section    -   g) at said destination router, removing said compressed header        section.

This method makes header compression doable for packet headers also in anarrow-bandwidth access networks over multiple links.

An embodiment of this method comprises a step of transmitting a headercompression context from said originating router to said intermediaterouters and to said destination router before performing the mentionedmethod steps.

A further embodiment comprises, at said originating router (A, 64), astep of assigning a header compression context identifier to said headercompression context, and a step of including said header compressioncontext identifier into said compressed header section.

According to a further aspect of the present invention a decompressordevice is provided, comprising an input interface adapted to receive atleast one data packet with compressed data, a decompressing meanscommunicating with said input interface and adapted to decompress saidcompressed data such that decompressed data are created based on saidcompressed data, and an output interface communicating with saiddecompressing means and adapted to provide said decompressed data ofsaid data packet. According to the present invention, the decompressingmeans is adapted to selectively decompress only compressed header datacontained in a header section of said data packet.

The selectivity provided by the decompressor of the invention reducesthe processing load in decompression of a header section of a datapacket. In concentrating on data relevant for routing according to themethods described above the decompression becomes more effective and,thus, faster. By leaving all other data compressed a very fast timingperformance can be achieved by this decompressor.

In a preferred embodiment of the decompressor device of the invention,the decompressing means has access to a header compression context tableand is adapted to decompress said compressed data using data containedin at least one predetermined section of said header compression contexttable, and at least one predetermined decompression algorithm. Using theaccess to the header compression context table it is possible to deducethe uncompressed header data. Header compression often involvesincluding only the difference between the data in the header compressioncontext and the corresponding data in the present header in thecompressed header section. By accessing the header context table theoriginal data of the present header can be restored using simplemathematics.

According to a preferred embodiment of the decompressor of the inventionthe decompressing means is adapted to decompress from the compressedheader section an identifier of an external network node that is thedestination of the data packet.

According to a third preferred embodiment of the invention thedecompressing means is adapted to decompress the complete compressedheader section of the data packet. This way the full header informationcan be used. This advantage is paid for with a higher processing load.

According to an implementation of the first or second preferredembodiment the decompressing means is adapted to additionally decompressa service classification code element from said compressed headersection. This allows a router the decompressor is connected to toperform the service classification and prioritization described above.

According to a further aspect of the invention a router device isprovided, comprising at least one input port adapted to receive a datapacket through at least one first communication link, and a plurality ofoutput ports. The router device of the invention comprises at said inputport a decompressor as described above.

The router device of the invention enables routing according to themethods described earlier. This provides fast and reliable routing alsoin an network environment with low-bandwidth links and in which packetloss cannot be excluded, such as in an IP RAN. The router of theinvention is especially adapted to be embedded in IP RAN nodes such asan IP node B and IP RNC.

The router allows to do decompression of transport header data only inthe middle of the IP access network header compressed transport,avoiding the need to compress again. Thus, CPU capacity is saved,especially in star points of a microwave access network. Thedecompression can also be reduced to a minimum using the decompressordescribed earlier, allowing a further reduction of CPU load.

The router is especially adapted to the role of an intermediate router.However, in a preferred embodiment the router of the invention is ableto switch to the role of an originating or a terminating node in atransmission path as well. This may even be done on a per-flow basis,such that the router is an originating router for a first packetreceived belonging to a first flow at a first input port from a terminaldevice, an intermediate router for a second packet belonging to a secondflow arriving at a second input port from a second router, and aterminating router for a third data packet belonging to a third flowreceived through a third input port from another router. However, therouter may additionally also comprise an input port that is not equippedwith a decompressor according to the invention. In a preferredembodiment of the router device of the invention, at least one inputport further comprises attaching means communicating with saiddecompressor, and adapted to attaching to the data packet data receivedthrough said output of said decompressor. Thus, the attaching meansproduce an “intermediate” data packet which is forwarded in this stateonly within the router device. The decompressed data attached to thedata packet will be used by the router device to perform the routingstep.

Preferably, the attaching means is adapted to attaching said data tosaid data packet in front of the compressed header, such that saiddecompressed header data can be forwarded within the router devicebefore said compressed header. This allows to analyze the decompressedheader data before the whole extended data packet is received and/orstored.

In a further preferred embodiment, the router device of the inventioncomprises routing means communicating with said attaching means and withsaid output ports, and comprising lookup means adapted to determine,based on routing information contained in said data packet and based ona routing table, at least one destination output port, and forwardingmeans communicating with said routing means and adapted to forward saiddata packet to said determined output port.

A further embodiment of the router device of the invention furthercomprises removing means communicating with said lookup means and withsaid forwarding means, and adapted to remove from said data packet saiddecompressed data attached by said attaching means. This way, removal ofthe attached data is done before the data packet is passed through theswitching fabric. This further increases the speed with which a datapacket is forwarded through a router device. The delay in thetransmission path of the data packet is reduced.

According to a further aspect of the invention a router device isprovided for routing at least one data packet with a compressed headersection, comprising at least one input port adapted to receive said datapacket through at least one first communication link, and a plurality ofoutput ports, wherein said input port comprises a reading unit adaptedto read a first header compression context identifier from saidcompressed header section of said data packet, and a switching unitadapted to replace said first header compression context identifier by asecond header compression identifier.

The present router device is especially designed to work according tothe first implementation of the first preferred embodiment of therouting method of the invention, in which routing is based on the HCCIDalone and the data packet receives a new outgoing HCCID unique for thelink to the next hop.

In a preferred embodiment of this router device, said switching unitcommunicates with, i.e., has reading and/or writing access to aswitching table that, as described in detail in context with the routingmethod, assigns to said first (incoming) header compression contextidentifier said second (outgoing) header compression context identifierand an output port identifier. The output port identifier is preferablya number uniquely assigned to one output port.

An implementation of the preferred embodiment has a control unitcommunicating with said reading unit and said switching table. Thecontrol unit is adapted to detect a new first header compression contextidentifier received at said reading unit, to assign a new second headercompression context identifier and at least one output port identifierto said first header compression context identifier, and to create atleast one entry in said switching table for said identifiers, one foreach assignment of an output port. Multiple assignment of output portsis used for implementing multiple links functionality.

In a further implementation of said router device the control unit isadditionally adapted to erasing said entry in said switching table givena predetermined condition, as described before in the context of therouting method with reference to aging.

Preferably, the invention is applied to a communication network,comprising a plurality of network nodes communicating with each otherthrough a plurality communication links. By including network nodes witha router device according to the above description, the transmissionspeed in the network can be increased. Also the delay is reducedespecially in networks including radio or microwave communication links.The invention is most preferably applied in a communication networkusing IP as a network layer protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the present invention will be described in greaterdetail based on preferred embodiments with reference to the figures, inwhich:

FIG. 1 shows a block diagram of a decompressor;

FIG. 2 shows a block diagram of a router device according to a firstpreferred embodiment, including the decompressor of FIG. 1;

FIG. 2 a shows a block diagram of an input unit of a router deviceaccording to a second preferred embodiment;

FIG. 3 shows a data packet as forwarded within the router of FIG. 2 a;

FIG. 4 shows a network system with routers according to FIG. 2 or 2 a;

FIG. 5 shows a flow diagram of a routing method implemented in therouter of FIG. 2; and

FIG. 6 shows a flow diagram of a routing method implemented in therouter of FIG. 2 a.

DESCRIPTION OF THE PREFERRED EMBODIMENT

A preferred embodiment of the decompressor device of the invention willnow be described on the basis of according to FIG. 1.

FIG. 1 shows a block diagram of a decompressor 10. The block diagram issimplified in order to only show the elements of relevance to thepresent invention. Accordingly, decompressor 10 comprises an input unit12, a decompressing unit 14, and an output unit 16. Output unit 16comprises a first output 16.1 for compressed packet data and a secondoutput 16.2 for decompressed packet data. Decompressing unit 14 isconnected for reading access to a header compression context table 18.To keep the functionality of decompressing unit 14 simple, headercompression context table 18 is maintained at the current state byexternal units as will be seen below in the description of FIG. 2. Thisis indicated by an arrow 20.

Input unit 12 is adapted to receiving compressed data packets andforwarding them to decompressing unit 14. Input unit 12 may compriseseveral input interfaces (not shown) for use of the present decompressoras a central decompressor unit in a router with several input ports. Inthis case input unit 12 also comprised means to control the order ofdata packets forwarded to decompressing unit 14.

Decompressing unit 14 is adapted to receiving compressed data packetsfrom input unit 12. The packets are decompressed by decompressing unit14 according to a predetermined algorithm, or one of a plurality ofpredetermined decompression algorithms. For this, decompressing unit 14accesses header compression context table 18.

Decompressing unit 14 only decompresses a predetermined header sectiondepending on the routing mechanism of the invention to be used.Therefore, decompressing unit 14 has two output links 14.1 and 14.2 tooutput unit 16. The twofold output of decompressing unit 14 comprisesthe compressed data packet as received through input unit 12 over outputlink 14.1, and decompressed header data restored from the data packet,over output link 14.2.

Due to the compatibility of the decompression algorithm used bydecompression unit 14 with the compression algorithm used by the routerthat created the compressed header of the received data packet, theposition of the predetermined header section to be decompressed in thedata flow received through input unit 12 is known. A counter (not shown)is preset upon the reception of a data packet in order to determine thecorrect bit position within the data packet received from said inputport. Alternatively, where packet data is transported in parallel frominput unit 12 to decompressing unit 14, the bit positions of the headersection to be decompressed are predetermined in correspondence to thecompression algorithm used.

Using the predetermined number of bits of the header section to becompressed and the information given by the header compression contexttable 18, header section data of the compressed header section arerestored and forwarded to output 16.2 using output link 14.2.

The decompressor of FIG. 1 may be used to decompress any section of anincoming data packet. Decompressing unit 14 comprises a control unit(not shown) that determines which section of a data packet is to bedecompressed. Decompression may comprise any number of bits, e.g., onebit, all bits of the compressed header section, or all bits of the datapacket.

With reference to FIG. 2, in the following a preferred embodiment of arouter 22 according to the invention will be described. Again, the blockdiagram of FIG. 2 serves only to explain the features relevant for thepresent invention.

Router 22 comprises a number of input ports, two of which are shown withreference numbers 24 and 26. A switching fabric 28 communicates withinput ports 24 and 26, a routing processor 30 and a number of outputports, two of which are shown with reference numbers 32 and 34.

The following description focuses on the structure and function of inputports 24 and 26. While there is no structure shown in FIG. 2 for inputport 26 it is the same as that of input port 24, and not shown here forreasons of simplicity only. Again, also the structure of input port 24is simplified in order to show only those elements relevant in thecontext of the present invention.

Input port 24 comprises decompressor 10 communicating with an attachmentunit 36. Attachment unit 36 is connected to a lookup unit 38 which is inturn connected to a routing table and a removing unit 42. Removing unitis also connected to switching fabric 28.

A data packet received at input port 24 will be processed bydecompressor 10 as described above. Decompressed data and theheader-compressed, unchanged data packet will be received by attachmentunit 36 which attaches the received uncompressed data to theheader-compressed data packet. The structure of the data packet thatattachment unit 36 forwards to lookup unit 38 will be described belowwith reference to FIG. 3.

Lookup unit 38 performs the function that is central to the switchingfunction of the router. A choice of an output port is made usinginformation contained in routing table 40. Routing table 40 assignsoutput ports to header compression context identifiers (HCCID). Lookupunit 38, therefore, by looking up in routing table 40 determines theoutput port assigned to the HCCID extracted from the packet header bydecompressor 10 and attached to the data packet by attachment unit 36.For example, the assigned output be 32. Routing table 40 is maintainedon a regular basis by routing processor 30. It may also assign serviceclassification information to the HCCID. The data packet is forward tothe determined output port through switching circuit 28. Before enteringswitching circuit 28 all data attached to the data packet by attachmentunit 36 are removed again. An exception is only made for the DiffServCode Point (DSCP) which will be removed immediately before placing thedata packet in an assigned queue (not shown) at the assigned output port32.

FIG. 2 b shows a block diagram of an input port of an alternativepreferred embodiment of the router of the present invention. Only inputport 124 of the router is shown because this is the only structuraldifference to the router of FIG. 2. Thus, replacing input ports 24 and26 of FIG. 2 each by an input port 124 of FIG. 2 a will result in arouter device according to the present preferred embodiment.

Input port 124 comprises a reading unit 110. Reading unit 110 seriallyreceives data packets. Reading unit 110 ascertains whether or not theheader of the packet contains a compressed header section. It reads andcopies a HCCID contained in each header-compressed packet. The HCCID iscontained as uncompressed data in the packet header. The packet isforwarded to a switching unit 114 through a first link 110.1, which maybe serial connection or, preferably, a parallel data bus.

The copied data is forwarded in parallel to a control unit 112 and tothe switching unit 114 through a second link 110.2, which may be serialconnection or, preferably, a parallel data bus.

Switching unit 114 refers to a switching table 116 for assigning anoutput port to the received data packet depending on the incoming HCCIDand on the DSCP, and for replacing the incoming HCCID by an outgoingHCCID. The DSCP is available from the header compression context table.Switching table 116 has four columns, one for incoming HCCIDs, one foroutgoing HCCIDs, one for the DSCP, and one for assigned output portidentifiers. In case the TTL field is carried as uncompressed data inthe packet, switching unit 114 will further decrement the TTL fieldvalue. The header-compressed packet will be forwarded to the assignedoutput port through switching fabric 28. It is noted that including theDSCP in the switching is optional.

In case there is no entry for the incoming HCCID in the switching tablethe incoming data packet will be a header compression context andtherefore not contain compressed header sections. Switching unit 114will perform regular routing for such uncompressed packets. It willassign an output port identifier and an outgoing HCCID to the packet.This assignment is made using the received destination and service classdata and a routing table (not shown) which is based on a routingalgorithm. The outgoing HCCID is written into the data packet in placeof the incoming HCCID. The uncompressed packet will be forwarded to theassigned output port through switching fabric 28.

Switching unit 114 will forward the data quadruple containing theincoming and outgoing HCCID, the DSCP and the assigned output portidentifier to control unit 112.

Control unit 112 will then create at least one entry in a switchingtable 116 for said identifiers, one entry for each assignment of anoutput port in case of support for multiple links.

With reference to FIG. 3, the structure of a data packet 44 that appearsat the output of attachment unit 36 of FIG. 2 is shown. Data packet 44comprises a payload section 46, a header section 48 and an attachmentsection 50. While payload section 46 comprises the data to betransported from the original application to the destinationapplication, header section 48 includes a number of subheaders accordingto different protocol layers. Attachment section 50 comprises thedecompressed header data that were attached to the data packet 44 byattachment unit 36.

FIG. 3 shows that the attached data appear at the very head of the datapacket. This means that they are forwarded first to the lookup unit 38.There, the attached data may be immediately analyzed for lookup purposessuch that routing can be done while the data packet is still beingreceived by lookup unit 38.

With reference to FIG. 4 an embodiment of the method of the inventionwill be described in more detail. FIG. 4 shows a network structure.Circles represent network nodes. For the purpose of the presentdescription four access-network routers are shown with reference lettersA, B, C and D. Two core-network routers are shown with reference numbers62 and 64. Lines between circles represent communication links. Thinlines represent wireless links. Wireless links 52, 54, 56, and 58 areshown for the purpose of this description. Fat lines represent fiberlinks. Fiber link 60 between network nodes 62 and 64 is shown for thepurpose of this description.

As an example, we assume that the header compressed transmission is donefor a path comprising access-network nodes A, B, C, and D. Nodes A, Band C are routers. Node D need not be a router, if it is the destinationof the packet. If not, D is a router. Routers A and 64 comprise acompressor performing header compression according to a predeterminedalgorithm. Router 62 and node D comprise a decompressor, performingheader decompression according to a corresponding, predetermineddecompression algorithm that allows to restore the original uncompressedheader data.

First, a header compression context identifier is assigned to a givenheader compression context (HCC) in router A. The header compressioncontext identifier (HCCID) is a unique number identifying the headercompression context that is used to decompress a compressed header. TheHCCID is carried in full headers and compressed headers. The HCCID canbe a small number. Router A will forward the data packet to router Bincluding in the compressed header section containing the HCCID.

There is no header compression in the core network. Therefore, router 62is a first destination node for the header compressed flow. Router 64 isa second originating node for the header compressed flow to router D. Aheader compression context is created and maintained by each router inthe transmission path from router A to router D. The HCCID is unique ineach link, i.e., it has a unique value in router A for the link torouter B pertaining to this header compression context, a differentunique value in router B for the link to router 62, pertaining to thisheader compression context, and so on.

Router B uses the HCCID for routing the packets originating at router Aon to router 62 without changing the compressed headers of the packets.No compression is used on the transmission path from router 62 to router64. . For this, router B will create and maintain a switching tablerelated to the particular input port in the following manner: afterreceiving the header compression context and the HCCID through a giveninput port from router A, a switching table entry is created in router Bthat assigns to the incoming HCCID the next hop, an output port for thenext hop, and an outgoing HCCID.

When a packet with the incoming HCCID has arrived at this input port ofrouter B, router B will look up the HCCID in the switching table. Thenrouter B will pass the data packet through its switching fabric andforward the data packet to router C through the assigned output port.The compressed header of the data packet is not changed by router B.Router 62 will decompress the header and forward it on to router 64using the routing information contained in the compressed headersection.

Router 64 will act like router A. Router C will act like router B. Afterreceiving the header compression context and the HCCID through a giveninput port from router 64, a switching table entry for this input portis created that assigns to the incoming HCCID a next hop, an output portfor the next hop, and an outgoing HCCID. When a packet with the incomingHCCID has arrived at this input port of router C, it will look up theHCCID in the routing table and will pass the data packet through itsswitching fabric and forward the data packet to router D through theassigned output port. The compressed header of the data packet is nottouched by router C.

Finally router D will decompress and remove the compressed header,attach the header to the payload of the data packet and rout the packetto the egress interface.

With reference to FIG. 5 a flow diagram of a routing method implementedin the router of FIG. 2 is shown. The routing method is started in astep S10 upon arrival of a data packet at an input port. In a step S12the router checks if it is the first router in the header-compresseddomain. If this is the case, i.e., the router has the role of router Aof FIG. 4, the header of the data packet is compressed in a step S 14.After that step S26 is performed as will be described below.

If the router determines that it is not the first router in the headercompressed domain, it will in a step S16 decompress a section of theheader or the complete header, depending on the particular embodiment ofthe router, as explained above. For the present example, we assume thatthe whole header is decompressed. In a step S18 the router checks if itis the last router in the header-compressed domain. If this is the casethe router will remove the compressed header in a step S20. Since nomore routing is necessary the routing method is finished in a step S22.

However, if in step S18 the router determines that it is not the lastrouter in the header-compressed domain, it attaches in a step S24 thedecompressed header data to the data packet. In a step S26 it will routethe packet to the correct egress interface.

Next, a classifying step S28 is performed in which the DSCP of the datapacket is determined and the packet is assigned a corresponding queue atthe assigned output port. The decompressed header data will then beremoved from the data packet in a step S30. Finally, the data packetwill be forwarded to the next router in a step S32. After this, therouter waits for the next packet to switch back to step S12.

With reference to FIG. 6 a routing method will be described that isimplemented in the router of FIG. 2 a. The method is started in a stepS100. In a following step S110 a data packet is received at an inputport 110. If the received data packet does not contain a compressedheader section, the packet is routed to an assigned output port. Thisassignment is based on a routing table. Further, HCCID and destinationaddress are extracted, i.e., copied from the header, and an outgoingHCCID is assigned and written to the data packet, replacing the incomingHCCID (steps 116 and S118). In a step S120 the switching table ismaintained by creating an entry for the new incoming HCCID, as describedwith reference to FIG. 2 a. The packet is then forwarded to the assignedoutput port.

If in step S112 it is ascertained that the packet does contain acompressed header the method continues at step S124 with reading theincoming HCCID from the packet header. The packet will at step S126 berouted to the assigned output port according to the pertaining switchingtable entry. Then, the HCCID will be replaced in the packet header bythe assigned outgoing HCCID in step S128. Finally, the packet will beforwarded to the assigned output port.

Application of the invention is especially considered for RTP/UDP/IP andUDP/IP header compression.

1. A method for routing a data packet comprising a header section and apay-load section, said header section comprising a compressed headersection containing coded information including routing information,comprising the steps of: receiving said data packet at an inputinterface routing said data packet to an output interface forwardingsaid data packet to said output interface, wherein said routing stepcomprises ascertaining said routing information from said compressedheader section, and wherein said coded information is left unchanged insaid routing and forwarding steps.
 2. A method according to claim 1,wherein said ascertaining step comprises a step of reading a firstheader compression context identifier from said com- pressed headersection.
 3. A method according to claim 1, wherein said routing stepcomprises a step of assigning a second header compression contextidentifier to said data packet and a step of-replacing said first headercompression context identifier by said second header compression contextidentifier in said data packet.
 4. A method according to claim 3,wherein said second header compression context identifier is one of apredetermined set of numbers.
 5. A method according to claim 3, whereinsaid assigning step comprises a step of looking up said second headercompression context identifier in a switching table, said switchingtable uniquely assigning to said first header compression contextidentifier said second header compression identifier and one of aplurality of output interfaces.
 6. A method according to claim 5,further comprising a step of maintaining said switching table.
 7. Amethod according to claim 6, wherein said maintaining step comprisesreceiving and saving an incoming header compression context.
 8. A methodaccording to claim 7, wherein said maintaining step further comprisesreading said first header compression context identifier and adestination address from said header compression context.
 9. A methodaccording to claim 8, wherein said maintaining step further comprisesassigning one of a plurality of output interfaces to said first headercompression context identifier based on a routing table, said routingtable assigning said output interface to said destination address.
 10. Amethod according to claim 9, wherein said maintaining step furthercomprises a step of assigning said second header compression contextidentifier to said first header compression context identifier.
 11. Amethod according to claim 10, wherein said maintaining step furthercomprises a step of creating a new entry in said switching table foreach incoming header compression context, said entry comprising saidfirst header compression context identifier, said second headercompression context identifier, and said output port.
 12. A methodaccording to claim 6, wherein said maintaining step comprises a step oferasing an entry from said switching table given a predeterminedcondition.
 13. A method according to claim 1, comprising, before saidrouting step, a step of decompressing said routing information from saidcompressed header section.
 14. A method according to claim 13 whereinsaid decompressing step comprises decompressing said complete compressedheader section.
 15. A method according to claim 13, wherein saiddecompressing step comprises decompressing an address of a destinationnetwork node.
 16. A method according to claim 13, wherein saiddecompressing step comprises decompressing a service classification codeelement.
 17. A method according to claim 13, comprising, after saiddecompressing step, a step of including at least a part of saiddecompressed header section into said data packet.
 18. A methodaccording to claim 17, wherein said part of said decompressed header isattached to said data packet in front of said header section, such thatsaid part of said decompressed header can be forwarded before saidheader section.
 19. A method according to claim 17, comprising, a stepof removing at least a part of said decompressed header from said datapacket.
 20. A method according to claim 19, wherein said removing stepis performed after said routing step.
 21. A method according to claim 2,comprising a step of classifying said data packet according to a serviceclass.
 22. A method according to claim 21, wherein said classifying stepis performed after said routing step.
 23. A method according to claim21, wherein said classifying step comprises a step of reading a serviceclassification code element from a header compression context table. 24.A method according to claim 22, wherein said classifying step isperformed before said removing step.
 25. A method according to claim 19,wherein said removing step comprises removing said decompressed headerdata except for said service classification code element.
 26. A methodaccording to claim 21, wherein said forwarding step comprises a step ofplacing said data packet into one of a plurality of queues, the chosenqueue corresponding to a value of said classification code point.
 27. Amethod according to claim 25, comprising a step of removing said serviceclassification code element before said placing step.
 28. A methodaccording to claim 1, wherein said forwarding step comprises radio ormicrowave transmission of said data packet.
 29. A method for routing adata packet with a header section and a payload section from anoriginating router to a destination router through at least oneintermediate router, comprising the steps of a) at said originatingrouter, routing said data packet to said intermediate router b) at saidoriginating router, compressing at least a part of said header sectioncontaining routing information c) forwarding said data packet from saidoriginating router to said intermediate router d) at said intermediaterouter, which is communicating with said originating router through saidinput interface, performing a routing method according to claim 1, saidoutput interface communicating with a next intermediate router or saiddestination router, respectively, e) repeating step d) for any furtherintermediate router, f) at said destination router, decompressing saidcompressed header section g) at said destination router, removing saidcompressed header section.
 30. A method according to claim 29,comprising a step of transmitting a header compression context from saidoriginating router to said intermediate routers and to said destinationrouter before performing the method steps of claim
 29. 31. A methodaccording to claim 30, comprising, at said originating router, a step ofassigning a header compression context identifier to said headercompression context, and a step of including said header compressioncontext identifier into said compressed header section.
 32. A methodaccording to claim 31, wherein said header compression contextidentifier contains a network address of said originating router.
 33. Adecompressor device, comprising an input interface adapted to receive atleast one data packet containing compressed data, a decompressing meanscommunicating with said input interface and adapted to decompress saidcompressed data such that decompressed data are created based on saidcompressed data, and an output interface communicating with saiddecompressing means and adapted to provide said decompressed data ofsaid data packet, wherein said decompressing means is adapted toselectively decompress only compressed header data contained in a headersection of said data packet.
 34. A decompressor device according toclaim 33, wherein said decompressing means has access to a headercompression context table and is adapted to decompress said compresseddata using data contained in at least one predetermined section of saidheader compression context table, and/or using at least onepredetermined mathematical decompression rule.
 35. A decompressor deviceaccording to claim 33, wherein said decompressing means is adapted todecompress from said compressed header section an identifier of anexternal network node that is the destination of said data packet.
 36. Adecompressor device according to claim 35, wherein said decompressingmeans is adapted to decompress only said identifier of said network nodethat is the destination of said data packet.
 37. A decompressor deviceaccording to claim 33, wherein said decompressing means is adapted todecompress said complete compressed header section of said data packet.38. A decompressor device according to claim 33, wherein saiddecompressing means is adapted to decompress a service classificationcode element from said compressed header section.
 39. A router device,comprising at least one input port adapted to receive a data packetthrough at least one-first communication link, and a plurality of outputports, wherein said input port comprises a decompressor according toclaim
 33. 40. A router device according to claim 39, wherein said inputport further comprises attaching means communicating with saiddecompressor and adapted to attaching to said data packet data receivedthrough said output of said decompressor.
 41. A router device accordingto claim 40, wherein said attaching means is adapted to attaching saiddata to said data packet in front of said header section, such that saiddecompressed header data can be forwarded before said header.
 42. Arouter device according to claim 39, further comprising routing meanscommunicating with said attaching means and with said output ports, andcomprising lookup means adapted to determine, based on routinginformation contained in said data packet and based on informationcontained in a routing table, at least one destination output port, andforwarding means communicating with said routing means and adapted toforward said data packet to said determined output port.
 43. A routerdevice according to claim 42, wherein said routing means furthercomprises or communicates with removing means communicating with saidlookup means and with said forwarding means, said removing means beingadapted to remove from said data packet said decompressed data attachedby said attaching means.
 44. A router device for routing at least onedata packet with a compressed header section, comprising at least oneinput port adapted to receive said data packet through at least onefirst communication link, and a plurality of output ports, wherein saidinput port comprises a reading unit adapted to read a first headercompression context identifier from said compressed header section, anda switching unit adapted to replace said first header compressioncontext identifier by a second header compression identifier.
 45. Arouter device according to claim 44, wherein said switching unitcommunicates with a switching table assigning to said first headercompression context identifier said second header compression contextidentifier and at least one output port identifier.
 46. A router deviceaccording to claim 45, further comprising a control unit communicatingwith said reading unit and said switching table, and adapted to detect anew first header compression context identifier received at said readingunit, to assign a new second header compression context identifier andan output port identifier to said first header compression contextidentifier, and to create at least one entry in said switching table forsaid identifiers, one entry for each assignment of an output port.
 47. Arouter device according to claim 46, wherein said control unit isadditionally adapted to erase said entry in said switching table given apredetermined condition.
 48. A communication network, comprising aplurality of network nodes communicating with each other through aplurality communication links, characterized in that said communicationnetwork comprises a network node with a router device according to claim39.
 49. A communication network according to claim 48, wherein at leasta part of said communication links is a radio or microwave communicationlink.
 50. A communication network according to claim 48, wherein saidnetwork nodes use an Internet Protocol as a network layer protocol.